HyperLib 1997 Winter - Disc 1/HYPERLIB-1997-Winter-CD1.ISO.7z/HYPERLIB-1997-Winter-CD1.ISO/オンラインウェア/UTIL/OtherMenu 1.8.3 folder.sit/OtherMenu 1.8.3 folder/OtherMenu folder/OtherMenu Manual.rsrc/TEXT_1600_GC Patch Technical Info.txt

Text File | 1996-02-11 | 3KB | 22 lines

General Controls Patch Technical Information
For Programmers Only

ﾂｩ1995 by James W. Walker

Here is the down and dirty info about what the General Controls panel does to cause a conflict, and what I propose to do about it.

Among other things, the INIT resource in General Controls patches _Pack3, the Standard File trap.  Its purpose in doing so is to implement the control on the initial directory shown in directory dialogs, as shown in the lower right corner of the panel.

Most trap patches are of two types:

1.  A standard 窶徂ead patch窶 leaves the original arguments and return address on the stack, performs some action, and jumps to the previous address of the trap.

2.  A standard 窶徼ail patch窶 calls the previous address of the trap as a subroutine, which involves copying the arguments, perhaps with modifications.  This type is easier to write in a high-level language.

The patch in General Controls is an odd hybrid.  It窶冱 like a tail patch, in that control returns to the patch after the original trap routine has executed, but like a head patch, it does not make a copy of the arguments.  Here is what it does:  It saves the return address from the stack into a fixed location in its own code block, and then replaces the return address on the stack with an address in its code.  Then it jumps to the previous trap address.  When the old trap code is done, it returns to the General Controls patch, which does more work and returns to the address that was saved in its code block.

Now, do you see why the General Controls patch is not reentrant?  Let窶冱 say an application, call it WordMeister, calls StandardPutFile.  The GC patch saves the return address, which points to somewhere in WordMeister窶冱 code.  Then, while that dialog is still displayed, you invoke an OtherMenu external, say Delete, that calls StandardGetFile.  The GC patch starts up again, and saves the return address, which points to somewhere in Delete窶冱 code.  But notice that this has wiped out the return address that pointed into WordMeister窶冱 code!  Thus it has planted the seeds of destruction.  When the Delete dialog is dismissed, it correctly returns to the Delete code, which finishes up and returns control to WordMeister窶冱 save dialog.  But when the save dialog is dismissed, the GC patch tries to return to Delete again, which is no longer running.

To fix this problem without actually reprogramming General Controls, my idea was to patch _Pack3 after General Controls, in such a way that the return address seen by the GC patch is always the same.  In this way, when the GC patch overwrites a return address with another, no harm is done.  The return address for my patch is saved on the stack, above the arguments, rather than in a fixed location.

To ensure that my _Pack3 patch is installed immediately after GC窶冱 patch, I add my patch as an INIT resource in the General Controls file, and change the old INIT resource to type 'xNIT'.  When my INIT runs, it loads and executes the 'xNIT' resource, then installs its patch.